The Ericsson IP transport network management system (IPT-NMS) is a network management system that allows users to design, activate and maintain services in a packet- or circuit-switched network.
IPT-NMS unifies 4th Generation network portfolio elements (e.g., 0-3, IP, Ethernet, SDH, CES, WDM, MPLS-TP) under a common, multilayer, multi-domain (e.g., Broadband Access, Microwave, Optical, Edge) Network Management System. With a single network view and fully integrated operations, administration and maintenance (OAM) functionality, smoother network evolution is enabled for SDH-to packet, mobile backhaul, and the building of IP and Ethernet packet networks. IPT-NMS enhances operations with streamlined packet service provisioning across multiple layers and domains, a single, multi-visual (physical, logical, graphical, hybrid) layout with a fully integrated OAM function, and a comprehensive packet feature set for both Transport and virtual private network (VPN) environments.
Referring to FIG. 1, a data communication network 10 generally includes a plurality of data communication nodes 12 interconnected by a routing network 20. The routing network 20 may include a plurality of switches, such as routers 16, that route packets of data within the data communication network 10 based on routing information contained in packet headers. The routers 16 are connected via backbone communication channels 32, which are typically high bandwidth data communication channels. The nodes 12 access the routing network 20 via access channels 34 that are typically lower bandwidth channels. The backbone channels 32 and the access channels 34 may include any suitable physical communication medium, including optical, wired, wireless, etc., using any suitable communication protocol.
A “Network Service” refers to a service supported by a 4th Generation communication system, such as voice telephony, video telephony, video distribution, voice over IP (VoIP), virtual private networking, etc. A “Network Element” refers to a node within the network that receives, stores, processes and/or transmits data in the network. A network element can include a server, a database, a router, a gateway, etc. A “Network Service Model” is a model that represents the configured state of a single Network Service on one or more managed Network Elements. A Network Service Model defines the type and level of service that is allocated at the Network Element to support a particular Network Service. Network Service Models are therefore important tools for managing system resources in a data communications system.
A network management system enables a user to design a Network Service Model and to store the Network Service model in an internal database of the network management system. The network management system can verify the integrity of the Network Service Model before the Network Service is actually implemented. Network Services can then be activated using a designed and tested Network Service Model.
The Network Service Model generation process is illustrated in FIGS. 2 and 3. As shown therein, a network management system includes a model generation engine 52 and a database or store 54 of stored Network Service Templates. The model generation engine may receive network definitions that define the topology of the network and user specifications that define the requirements for a particular Network Service. The network definitions may be obtained from a data store that may be local or remote from the network management system 50. In some cases, the network definitions may be obtained directly from managed Network Elements. The network management system and/or the user may select one or more Network Service Templates from the database 54, and the model generation engine 52 generates a Network Service Model from the selected Network Service Templates, the user specifications and the network definitions.
When a user designs and activates a Network Service via the network management system, one or more portions of the corresponding Network Service Model may be generated from one or more Network Service Templates. A Network Service Template is a template that is stored in a database of the IPT NMS and that provides a framework for designing a Network Service Model. A Network Service Template may not be associated directly with a Network Service. Rather, the Network Service Template exists purely within the network management system, and is not directly referenced by any part of the Network Element configuration.
During the Network Service design process, one or more Network Service Templates may be used for various purposes, such as filtering out incompatible Network Elements or configuration options from the service design workflow, providing sensible default values for configurable parameters, restricting configurable parameters based on service requirements, etc.
For instance, if a Network Service Template indicates that the service must provide a best-effort Committed Information Rate (CIR) of 1 Gbps, the network management system service design logic can prohibit the user from selecting device resources that are not capable of providing this throughput.
The Network Service Template continues to be useful even after the Network Service Model is activated in the network. For instance, the Network Service Template may be used to ensure that the current configuration of a Network Service matches its required configuration in the corresponding Network Service Model. For example, if an active Network Service is only capable of providing 100 Mbps throughput, but its corresponding Network Service Model is associated with a template requiring 1 Gbps throughput, the network management system can raise an alarm condition to indicate that this Network Service Model should be repaired by a service designer. This way, the network management system can use Network Service Templates to enforce customer Service Level Agreements (SLAs).
The Network Service Template can provide an “at-a-glance” characterization of a network service such as “Bronze/Silver/Gold DSL”, “50 MBit VPN” etc. Service Maintainers can use this characterization to determine how quickly to address or escalate faults.
When a network management system is installed in a network with existing Network Services (a so-called “Brown Field” network), part of the installation process may include generating a Network Service Model for each existing Network Service. This logic may be referred to as the Service Discovery process. Part of the Service Discovery process associates each generated Network Service Model with a Network Service Template.
The Service Discovery process is illustrated, for example, in FIG. 3. As shown therein, a network management system 50 receives a set of network definitions that define the topology of the communications network (block 62). The network management system 50 then discovers network services that are supported by the network, for example, by querying network elements (block 64). The network management system 50 then generates a network service model for the identified Network Services (block 66). Finally, the network management system 50 associates each network service model with one or more pre-existing network service template (block 68).
If the Service Discovery process does not exist, the network management system user may be required to manually create a Network Service Model corresponding to each existing Network Service as part of the network management system installation process. During this manual process, the user can explicitly associate a Service Template and one or more Endpoint Templates (Service Templates and Endpoint Templates are two types of Network Service Templates) with a generated Network Service Model. However, this manual process may present a great burden on the user when thousands or tens of thousands of Network Services exist in the network.
Conventionally, a network management system has three options for assigning a Network Service Template to a Network Service Model in the Service Discovery process.
First, the network management system can assign a “catch-all” Network Service Template to each new Network Service Model. This is not desirable because such a template must be generic enough to satisfy every potential Network Service Model. In this scenario, the network management system could not detect when the parameters of a specific Network Service no longer match its required configuration, and customer SLAs could not be guaranteed.
Second, the network management system could assign a new Network Service Template to each new Network Service Model. This approach is not desirable because it violates the one-to-many relationship from Network Service Templates to Network Services. That is, defining a new Network Service Template for each Network Service will produce too many Network Service Templates in the network management system's database, which eliminates the benefit of quickly characterizing a Network Service Model based on its associated Network Service Template.
Third, the user could manually assign an appropriate Network Service Template for each Network Service Model. This approach may present an unacceptable burden to users, since even a medium-sized user may have tens of thousands of services active in their network.